Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / pc / faqs.367 < prev next >

Wrap

Text File | 1996-02-09 | 28.8 KB | 620 lines

Frequently Asked Questions (FAQS);faqs.367 On the other hand, people sometimes leave out the higher levels of the address, as in "ferret.marketing". This is a bad idea - because if the mail is cc'd out of the organization, chances are the external recipient cannot reply, because "ferret.marketing" is incomplete. So use addresses that are specified sufficiently for external users to use. (fooinc.com if a organizational gateway is used, the whole ferret.marketing.fooinc.com if not) NIC Internet TOP-LEVEL domains (edu, com, gov, mil) are controlled by a single organization, the NIC (nic.ddn.mil). An organization "gets a piece" of the namespace by registering with the NIC, and then they are free to administer their own namespace (everything under fooinc.com) as they choose. The same is true for foreign countries; Once they have their top-level domain (usually the two-letter ISO country code) registered with the NIC, they do the rest, and divide it as they see fit. In contrast, on UUCPnet, all machine names everywhere share a single flat namespace. So it is important to choose a name that has not been used before. (See do's and don'ts). This is why FQDN's help. We can tell the difference between ferret.fooinc.com and ferret.blah.edu by their full names. (Instead of UUCP paths which may turn out to be wrong, and autorouting will probably send the mail to the wrong machine) MX record: A non-SMTP/Internet site that wishes to register on the Internet will need to get a "nearby" Internet site to set up a MX record for them. An MX record is essentially a domain-server database record that (effectively) registers your domain name on the Internet, and indicates that the Internet site knows how to forward mail to you. Usually via some non-SMTP/Internet route, such as UUCP. You can get an MX record for one site, or a "wildcard" MX record so that you can have your own subdomains. Bang-Paths: With UUCP mail, the MTA has to specify a route to get from one machine to another. "A!B!C!userid" means go to machine A, then B, then C, then user "userid" on C. You should strive, however, for a MUA that allows you to use domain addressing, and let the MTA figure out the bang routing as appropriate. Miscellaneous: Gateways: There are several meanings of this term, only three are relevant here. The first is a mechanism for getting from one network to another network that uses different protocols. The second is a mechanism for getting from one logical (often organizational) network to another using the same protocol. Often for example, there will be a LAN in one department of an organization, and one machine in the LAN has the connection to another LAN in another department. This means that mail from one LAN to the other has to pass thru the gateway machine. Another form, which we'll mention later is that of mail to news gatewaying. Routers: There are several definitions, but the most important is that part of the TA that figures out how to send a message to a given machine. This often uses a database that provides routes from one machine to the other machines on the network. Smarthost: In many cases, your machine won't know how to get to a specific destination. You can usually set up your mail system to send mail, that it doesn't know how to deliver, to a machine that is more likely to. RFC's: A set of documents that include formal descriptions of mail formats used on the Internet, and are adhered to by many non-Internet systems. More specifically, in the "worldnet" of USENET, Internet and UUCP, the RFC's set the standards for mail exchange. RFC822, 1123 and 976 are the most important for Internet/UUCP mail. It should be pointed out, however, that there are some regions where the RFC's are not entirely respected. For example, the British academic email networks (JANET) uses domains, but they're specified backwards (they drive on the wrong side of the road too ;-). MIME: Mime is the official proposed standard format for multimedia Internet mail encapsulated inside standard Internet RFC 822 messages. Facilities include sending multiple objects in a single message, character sets other than US-Ascii, multi-font text messages, non-textual material such as images and audio fragments, and other extensions. For an overview of Mime, see ftp.uu.net:mail/metamail/MIME-overview.txt.Z. The defining document is Internet RFC 1341: N Borenstein & N Freed, ``Mime (Multipurpose Internet Mail Extensions) mechanisms for specifying and describing the format of Internet message bodies'' (June 1992). Also see RFC 1344: N Borenstein, ``Implications of Mime for Internet mail gateways'' (June 1992). Mime covers only message bodies, not message headers; to see how to represent non-Ascii characters in message headers, see Internet RFC 1342: K Moore, ``Representation of non-Ascii text in Internet message headers'' (June 1992). X.400: A CCITT standard for email formats, more or less an alternative to RFC 822/976/1123. This format will probably start taking over from RFC 822/976/1123 mail. It is likely to (already has?) become an ISO/IEEE standard along with OSI etc. "The Maps": A set of files describing machine-to-machine links distributed over USENET in the group comp.mail.maps. These are usually posted on a monthly schedule, and can be automatically received and transformed into a routing database that describes the "optimal" route to each machine. These are operated by the "UUCP Mapping Project". See the README posted along with the maps for more details. Aliases: Aliases are a mechanism by which you can specify the destination for mail on your machine. Through the use of aliases you can redirect mail to "virtual userids". For example, you should have a mail destination on your machine called "postmaster", which is aliased to send the mail to the System Administrator (ie: you probably). Aliasing often also permits you to send mail to groups of users (not necessarily on the same machine as you) pipelines of commands or to specific files. Mailing lists: Are similar to USENET newsgroups. They are usually aliases pointing to groups of users, and allow mail to be sent to the whole group at once. Mailing lists are set up to carry certain subjects. The difference between a mailing list and a USENET newsgroup is that the messages are sent by mail, probably as a copy to each recipient, rather than broadcast. -------- Subject: Do's and Don'ts: 1) Register a domain name. Even on UUCP, where <machine>.UUCP is often used as a kludge, it is MUCH preferred that you obtain a real domain address. If you are directly connecting to the Internet, you will get one as part of your registration with the NIC. If you aren't connecting directly to the Internet, obtaining a registration will usually require you finding a nearby friendly Internet site willing to act as a mail forwarder to you from the Internet - the site that will set up a "MX record" for you. Many sites will do this for you for free, and several of the commercial email services (eg: uunet) will do it for you for a nominal charge (without requiring you buy the rest of their services). There are occasions where you can join what is called a "domain park". These are most often small regional groups of systems that have gotten one of their number properly registered as a domain, and provides forwarding services out to other systems. For example, in my address "ferret.ocunix.on.ca", "ocunix.on.ca" is a domain park made up of the Ottawa-Carleton UNIX User's Group, one of the other machines in the group provides a gateway between our systems and the Internet. 2) If your machine is going to "speak" UUCP to the outside world, choose a unique UUCP name. You can find out whether a name you want is taken by consulting the UUCP maps. Or by asking someone else who's using them. 3) Register your machine with the UUCP Mapping Project. Information on how to do this is included in the monthly maps postings in the file "README". This is usually only required when your machine talks UUCP to the outside world, or when other machines have to address you by your UUCP name. If you don't do this, somone else may choose the same name, and gross confusion will arise when smart routers won't be able to tell whether to send a piece of mail to you, or your doppelganger[s]. If you register with the UUCP Mapping Project, you have prior use, and people who choose the same name afterwards will be told to get a new one. If you're "behind" an organizational gateway, don't do this. (Your organizational gateway is the thing that needs to be registered) If you do fill in a map, please take the time to fill it in carefully, giving contact people and phone numbers. Just in case your machine goes crazy and starts doing something nasty. Note expecially the latitude and longitude. Get it right, or omit it. Brian Reid gets really annoyed with sites that are half a world away from where they really are. 3) If you're going to be setting up multiple machines, have only one or two connections to the outside world. 4) Install a mail system that understands domain addressing, even if you aren't registered. (In fact, all of the suggested configurations in this FAQ do) 5) *Never* use UUCP bang-routing with the MUA if you can possibly avoid it - each of the suggested mail configurations provide mechanisms where you, the user, do not have to specify routes to the MUA - you can specify domains, and the TA will do the routing (possibly bang-routing) for you. 6) Find a friendly neighboring SA to help. A SA who has already operating mail in your area will help smooth over the regional "gotchas" that are bound to crop-up. And advise you on the right software to use, where to obtain it, and how to install it. 7) Do NOT use "any old" Map unpacking program. Most available map unpacking programs automatically run the shell (or shar) to unpack map articles. Since it is trivially easy to forge map articles, using this type of unpacking program can easily let very destructive trojan horse or virus programs into your machine. The two specific map unpackers described in this FAQ are known to be secure from such attacks. Do not run any other unpacker unless you are aware of the issues and can inspect the code for such vulnerabilities. [If you know of other "secure" map unpackers that are generally available, please let me know] 8) If the people on your site, or small network, receive mailing lists, it's often a good idea to gateway them to news: Netnews often performs many of the same services as email. The primary difference is that messages are centrally stored, rather than delivered to individual's mailboxes, and that distribution looks more like a broadcast then a set of point-to-point communications. This means usually means that news can handle more volume, more efficiently, then email can. Because of the differences (and also the similarities) people often want to tie news and mail together. This is known as "gatewaying." For example, a small software development site might subscribe to the X Windows mailing list. Rather than have (say) eight copies of each mail message sent to their host, they would rather have it stored as a local newsgroup that everyone in the company can read, and which can be centrally archived. This is a typical use of a "mail to news" gateway. When a user makes a posting to this local group the article should be sent back out to the mailing list; this is a typical use of a "news to mail" gateway. On a larger scale, the "inet" groups are bi-directional gateways of Internet mailing lists. Within mainstream Usenet, many popular groups such as comp.windows.x, comp.protocols.tcp-ip, comp.unix.wizards, and so on, are gatewayed to mailing lists and back. Many subtle issues often come up when gatewaying mail and news, so unless you are experienced you should use one of the already-available packages for your local organization. For example, you probably do not want to write a brand-new Perl script and create a new "inet" newsgroup. The C News distribution includes some basic gateway tools in the contrib/nntpmail directory. Many people use Rich $alz's "newsgate" package that appeared in comp.sources.unix Volume 24; it includes discussion of some of the more subtle issues that come up. Before starting a mailing list gateway, apart from the technical aspect of the job you should also be aware of one important point: mailing-lists are considered private, whereas newsgroups are public. One can know who gets a list, but not who reads the group. It is always wise to get the authorization of the mailing-list manager and of the readers before creating a mail/news gateway. 9) If you're connecting to the Internet, or are setting up a large local internet, you really should get a copy of the DNS and BIND book mentioned in the bibliography. -------- Subject: Configuration Issues: What you need for email connectivity is determined by: 1 What networks you intend to connect to. The Internet (hence SMTP)? UUCP sites? X.400? Bitnet? Others? Combinations? 2 What links you have or are willing to install Internet T1? T2? UUCP? Other? [Details on how to make your connections is beyond the scope of this FAQ, but can usually be found out from the provider (other end) of the link] 3 what user interface you want to use. This is largely an independent issue, so consult the Specific Package Reviews directly. -------- Subject: Recommended MTA Configurations: These configurations are based upon my own experience, and the experience of others. Careful installation of any of these configurations will result in a solid, reliable mail system that respects the appropriate "do's and don'ts". Each configuration represents a compromise of ease of installation and maintenance versus sophistication and capabilities. One thing you should consider is what you already have on your system. You will invariably have "binmail", and will have a good chance at already having sendmail. Some systems come with smail (if 2.3, junk it) The configurations shown below are *minimal* configurations, so you should consider whether you want to use what you already have or not. Scenario 1: Only UUCP connections. Smail 2.5. If you want to set up a routing database of your own, you will also need pathalias, and unpackmaps or uuhosts. Instead, though, you can configure smail 2.5 to smart-host most destinations to a nearby friendly site who'll do your routing for you without having to run the routing software. Note further, that you can run pathalias on just a subset of the full set of maps. [Unpackmaps makes this particularly easy to do] Smail 2.5, as shipped, does not support mail-to-pipeline or mail-to-file aliasing. If you need these, at a minimum, you should obtain lmail. If you intend more than casual use of these features, it is recommended that you obtain deliver instead of lmail. Even if you have sendmail already, you can integrate smail 2.5 with it to do your UUCP routing. (though, some later versions of sendmail can do routing themselves) Scenario 2: SMTP connections (optionally, some UUCP connections too). Generally speaking, sendmail will do this for you and you have a good chance to have it already. However, for the novice, it is recommended that smail 3 be used instead [see review of sendmail below]. Smail 3 includes all of the routing software and can do mail-to-pipeline and mail-to-file, so none of the auxiliary programs mentioned in scenario 1 are necessary. Most sendmails don't include UUCP routing mechanisms, so you would need pathalias and unpackmaps or uuhosts if you wish to set up a UUCP routing database. Further, most sendmails don't know how to query a pathalias database directly, so you may have to hack your own path lookup program into the sendmail.cf (smail 2.5 can be used for this purpose provided that you will have a UUCP link to the outside world) Both MMDF and PP can also be used. Deliver or procmail are still quite useful in this configuration for extended alias facilities. Scenario 3: Connections to other networks (optionally including SMTP or UUCP), or very high loading. Your best bets are MMDF, PP or zmailer. You can implement other network interfaces with sendmail, but not only will you probably have to roll your own, but sendmail can't cope with high loading very well. Ditto smail 3. There are other configurations. See the Package Reviews to determine which packages are appropriate. -------- Subject: Package Reviews Honesty requires me to point out which software packages were reviewed by their author (including me ;-). I do so by appending a "*" to the name of the author. In some cases, the material has been cribbed from FAQ's or general information blurbs. It is worth noting, though, that most of these packages are well known, and have been in operation at many sites for periods of a year or more. These packages do their job well, and have been extensively thrashed out in the best debugging laboratory in the universe (USENET ;-) A few packages have been mentioned prior to their release. (unpackmaps 4, the occasional beta version). It is recommended that these versions be avoided by novices until they have had a chance to settle for a little while. This FAQ will note when such software seems (according to rumour *I* hear) to be stable enough for general use. Some of these packages are capable, by various bits of hackery, of doing a lot more than is claimed for them. But I refrain on telling you how to "take the covers off". Given the intended audience, that would be tantamount to trying to teach preschoolers do-it-yourself brain surgery. Please don't take this as condescending - I've been working on/in/with email systems for over 12 years and I *still* won't play with (as just one example) sendmail.cf's. Therefore, I restrict myself largely to "out-of-the-box" functionality, "fill-in-the-blank" configurability, and normal documented installation procedures. Beyond that, you're on your own. binmail binmail is usually really called "mail". On System V prior to Release 4, it is a really simple UA that does dual duty as the TA. It's pretty awful because it doesn't know how to set up headers properly, doesn't even know what a "Subject:" line is, and there's no way to do any kind of aliases. On BSD, binmail invokes sendmail to do the MTA function. On System V prior to Release 4, you really do want to replace binmail's MTA functionality with something else. However, you should not replace it in its "mail" (UA) functionality, because many system-level administration mechanisms will break. Any new UA should be installed as a different name than "mail". Beginning with System V Release 4, "binmail"'s transfer agent capabilities were considerably enhanced to have similar capabilities to Smail 3 and sendmail. There is usually no need to replace it with another mail agent. (See SVR4 mail discussion below) Binmail stores mail in "mbox" format. rmail binmail's TA functionality is implemented by linking mail to rmail. It's rmail that you'd want to replace with smail 2.5 etc. Mail The original BSD UA. It can support local profiles, aliases, folders, header previewing, out-going mail recording and all sorts of good stuff. An "okay" UA. Available from BSD "freed-sources" archives. Mail stores mail in "mbox" format. mailx AT&T's answer to BSD "Mail", from which it is descended. Some versions, such as the 3b1 one, should be avoided because of a buggy port. Not available in source form (it's proprietary but ubiquitous enough to be mentioned here). Mailx stores mail in "mbox" format. mush: author Dan Heller* <argv@z-code.com> The "Mail User's Shell" is a "shell" for mail users. That is, it has its own environment where you can configure not only the user interface, but the actual internal mechanisms. Internally, mush has a csh-like scripting language, altho it's not as powerful as csh. It has command-line aliases, file completion, if-else state- ments, command piping, and so on. Because you can build your own commands, you can virtually build your own library of email features. Mush has two tty-based interfaces: the standard tty-mode (ala BSD Mail or sys-v mailx) and the fullscreen/curses mode (ala vi, emacs or even Elm). You can set up key bindings that execute one or more mush commands, personalized commands or even UNIX commands. You can even emulate keyboard input with keyboard macros and mappings. Mush also has a SunView interface that is more powerful than Sun's Mailtool, yet backwards compatible with most versions. Most sunview users (if there are any left these days) prefer MushView over Mailtool. The current version of Mush is 7.2.3, last posted in comp.sources.misc volume 18 (with subsequent patches). All three interfaces are available in one runtime binary. Except for the MushView interface (which is only available on for suns), Mush is portable to everything that runs UNIX. There is also a DOS port available for PCs and can run on most 286 machines. An older version of Mush (6.5) can run on as little as 640 of RAM. (Mush-PC is typically used with UUPC.) The "next generation" of Mush is a commercial product called Z-Mail from Z-Code Software (mail argv@z-code.com for details). All aspects of Mush are retained, yet it has grown to be far more powerful. It runs under X windows with either a Motif or Open Look interface and also supports multi-media, user "functions" and a suite of new features. Third party documentation is available from O'Reilly in the book entitled "The Z-Mail Handbook" (by Hanna Nelson). This book not only covers Z-Mail, but Mush as well. Mush stores its messages in "mbox" format, or MMDF format if you're using MMDF as your MTA. The newsgroup comp.mail.mush is dedicated to it. [Note: Z-Mail is not related at all to Zmailer. Zmailer is a MTA] elm: coordinator Syd Weinstein* <syd@DSI.COM> (cribbed from comp.mail.elm FAQ) Elm is designed to run with "sendmail" or "/bin/rmail" (according to what's on your system) and is a full replacement of programs like "/bin/mail" and "mailx". The system is more than just a single program, however, and includes programs like "frm" to list a 'table of contents' of your mail, "printmail" to quickly paginate mail files (to allow 'clean' printouts), and "autoreply", a systemwide daemon that can autoanswer mail for people while they're on vacation without having multiple copies spawned on the system. The most significant difference between Elm and most other mail systems is that Elm is screen-oriented. Upon further use, however, users will find that Elm is also quite a bit easier to use, and quite a bit more "intelligent" about sending mail and so on. Current release is Elm 2.4 PL3. Information on access is available from the server at DSI.COM: send mail to archive-server@DSI.COM send elm index [Ed: elm is particularly good for novices. The only drawback that I've heard is that elm is a bit less user configurable than, say, mush] MM: Contact Joseph Brennan* <info-mm@cunixf.cc.columbia.edu> Columbia University in the City of New York (cribbed from MM man page.) mm is a powerful electronic mail system which allows you to send, read, edit and manage messages quickly and easily. It is designed to have the same interface as the MM program written and developed for DEC20s over a period of many years. mm was written using the CCMD package developed at Columbia. Thus, it has copious internal help, completion of partially typed commands on use of the TAB key, and help on partial commands when ? is typed. mm can read several mail-file formats. Its default is mbox, the same format used by unix mail. It also can read babyl, used by emacs rmail, and mtxt and MH. It can copy messages from one file type to another. MM is a Freeware MUA copyright by Columbia University (as is this description). MM is available by anonymous ftp from cunixf.cc.columbia.edu, directory mm. The file mm-intro.txt there is a longer description of how it was developed. [Ed: MM also appears to be a good UA for novices. From the examples in the manual page, it handholds extensively and is not screen oriented.] MH: Maintainer John Romine <Bug-MH@ics.uci.edu> The big difference between MH and most other "mail user agents" is that you can use MH from a UNIX shell prompt. In MH, each command is a separate program, and the shell is used as an interpreter. So, all the power of UNIX shells (pipes, redirection, history, aliases, and so on) works with MH--you don't have to learn a new interface. other mail agents have their own command interpreter for their individual mail commands (although the mush mail agent simulates a UNIX shell). Mail messages are stored in individual files. The current version of MH is 6.7.2. MH comes standard with Ultrix 4.0 and later, and AIX 3.1 and later. via anonymous ftp: ics.uci.edu [128.195.1.1] pub/mh/mh-6.7.tar.Z 1.6MB louie.udel.edu [128.175.1.3] portal/mh-6.7.tar.Z 1.6MB A new version of MH that supports multi-part multi-media mail is currently in alpha-test. comp.mail.mh discusses MH, and contains a FAQ article. GNU Emacs Rmail: Rmail is an Emacs subsystem for reading and disposing of mail. Rmail stores mail messages in Rmail files in BABYL format (originally used under the ITS operating system), although it can incorporate new mail from MMDF and Unix format files, or mixed-format files. Reading the messages in an Rmail file is done in a special major mode, Rmail mode, which redefines most letters to run commands for managing mail. Rmail can do the standard things such as displaying, deleting, filing, or replying to messages. Replying uses another Emacs subsystem, Mail mode. Messages can be saved in either BABYL or Unix format. Rmail maintains per-message attributes and user-defined labels. Rmail can burst message digests. VM: Author Kyle Jones* <kyle@uunet.uu.net> VM (View Mail) is a GNU Emacs subsystem that allows UNIX mail to be read and disposed of within Emacs. Commands exist to do the normal things expected of a mail user agent, such as generating replies, saving messages to folders, deleting messages and so on. There are other more advanced commands that do tasks like bursting and creating digests, message forwarding, and organizing message presentation according to various criteria. The current version of VM is VM 4.41. FTPable from: ab20.larc.nasa.gov pub/vm/vm-4.41.tar.Z ftp.uu.net pub/vm-4.41.tar.Z archive.cis.ohio-state.edu pub/gnu/emacs/elisp-archive/packages/vm-4.41.tar.Z VM is discussed in gnu.emacs.vm.info, or by mailing list by sending an e-mail request to info-vm-request@uunet.uu.net. MH-E: Maintainer: Stephen Gildea <gildea@bbn.com> MH-E is an interface to MH from within GNU Emacs. It helps if MH was compiled with the MHE compiler flag. MH-E is distributed with both GNU Emacs and MH. Choose the later version. C-Client: Author Mark Crispin <mrc@panda.com> Software writers only: C-client is a general library useful for creating MUA's. It provides a high level logical interface for retrieving and manipulating mail messages. It supports the latest draft of MIME (proposed Internet standard for multipart, multimedia, typed electronic mail). It is driver based, and easily ported to new platforms and MTA's, already supports BSD, SysV, DOS, Macintosh and TOPS-20(!), and supports present mail and mailbox formats.